It's still there, but the kernel doesn't offer it to the user. It is used by drivers that use the custom chips (like floppy, framebuffer, and sound) and for saving the kernel log (with the debug option documented earlier). The z2ram driver can use this memory, but this option doesn't always work right (as amifb, SCSI controllers and the sound driver may want to allocate chip memory for various purposes).
There is an ext2 filesystem for AmigaOS (available at http://titan.cs.bonn.edu/~fasten/). It allows you to read/write ext2 partitions. Not all write operations are currently supported. Important: Make sure you read the "Known bugs" section.
Other ways to transfer files from Linux to AmigaOS are to use an msdos partition, an Amiga/PC formatted floppy with msdos file system (this requires a Mountlist entry on AmigaOS side), use of a partition with Minix file system and the Minix file handler on AmigaOS side (the driver is somewhat unstable) or by accessing the floppy or any (empty!) partition directly via GNU tar.
You can also read and write Amiga partitions from within Linux (using the affs filesystem). Some older install guides say that affs is read-only, but that restriction was lifted in the 2.0 series of kernels (only Directory Cache disks are read-only in 2.x).
AmigaOS text files are normally formatted using Latin1 text; Linux normally defaults to using Latin1 encoding (also called ISO 8859-1), so you shouldn't have any problems. CR/LF problems should not appear either.
(written by Frank Neumann)
This problem seems to be related to certain A3000 Amigas: probably only those with BootROMs. It has been discovered that if you have a DAT drive connected whose SCSI address is smaller than the smallest SCSI address of a hard disk in your Amiga, the bus will lock up very early (under AmigaOS, while the SCSI bus is being scanned: you can notice this by seeing that the SCSI LED is constantly lit and nothing happens). The solution is to use higher address for DAT drives (and maybe also for CD-ROMs) and the lower ones for direct-access media (read that as "hard disks").
Linux/m68k can detect the Amiga's AutoConfig devices. That it is able to detect and correctly classify these devices does not mean that the kernel has an actual driver for that device. The list of supported hardware given earlier should be exhaustive, i.e. anything that is not listed is not supported. Note: turbo boards that appear as AutoConfig devices are almost always supported (except for the SCSI controller, if they house one).
If an AutoConfig device isn't properly detected, contact Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> for details on how to make sure it will be properly detected in future kernels.
Note that kernels after about 2.1.105 require the use of a separate "zorroutils" package to get human-readable information about your Zorro devices. This package should be available at Erlangen already, and is available as a Debian package in the unstable ("potato") distribution.
(written by Martin Apel)
What happens is that amiboot gets loaded into virtual memory and shoots itself out of accessible memory when disabling the MMU. But fortunately there's an easy way to solve this:
Enter amiboot into the task list of VMM with code and data set to "No VM". Then amiboot (version 3.0 or higher) should work correctly.
(written by Geert Uytterhoeven)
To compile these programs, you'll need the Amiga Developer's
Environment (the GNU tools for creating AmigaOS programs). Linux/m68k
binaries of ADE are available at
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/devel/ADE.tar.gz.
You will also want the ADE.readme file from the same location.
(written by Haidinger Walter)
By mounting. First you need a mount-point, i.e. a directory under which you can access your floppy. You can chose an arbitrary name, I use /df0 through /df3 (and /pc0 to /pc3 respectively) because I'm used to these names from AmigaOS.
Create the directories. e.g.:
mkdir /df0
mkdir /any-name-will-do
mkdir /ados/df0
mkdir /ados/pc0
...
Next, check if you have the proper device nodes: Type:
ls -l /dev | grep "^b.* 2, [0-7]"
For me, that lists:
brw-r--r-- 1 root wheel 2, 0 Mar 31 18:16 df0
brw-r--r-- 1 root wheel 2, 1 Mar 31 18:16 df1
brw-r--r-- 1 root wheel 2, 2 Mar 31 18:16 df2
brw-r--r-- 1 root wheel 2, 3 Mar 31 18:16 df3
brw-r----- 1 root 25 2, 0 Jun 22 1996 fd0-
brw-r----- 1 root 25 2, 4 Feb 26 1994 fd0d360
brw-r----- 1 root 25 2, 4 Jun 22 1996 fd0d360-
brw-r----- 1 root 25 2, 5 Jun 22 1996 fd1d360
brw-r--r-- 1 root wheel 2, 4 Apr 4 11:49 mfd0
brw-r--r-- 1 root wheel 2, 5 Apr 4 11:49 mfd1
brw-r--r-- 1 root wheel 2, 6 Apr 4 11:49 mfd2
brw-r--r-- 1 root wheel 2, 7 Apr 4 11:49 mfd3
brw-r--r-- 1 root wheel 2, 4 Mar 31 18:03 pc0
brw-r--r-- 1 root wheel 2, 5 Mar 31 18:16 pc1
brw-r--r-- 1 root wheel 2, 6 Apr 8 12:03 pc2
brw-r--r-- 1 root wheel 2, 7 Apr 8 12:03 pc3
^ ^ ^ =09 ^^^
block-device major minor node-name=20
Do not worry if you have other results. What do you need to know?
0 to 3 ... Amiga drives 0 to 3 (i.e. df0 to df3)
4 to 7 ... MS-DOS drives 0 to 3 (i.e. pc0 to pc3)
Now create the device-nodes:
mknod /dev/df0 b 2 0
mknod /dev/df1 b 2 1
mknod /dev/df2 b 2 2
mknod /dev/df3 b 2 3
mknod /dev/pc0 b 2 4
mknod /dev/pc1 b 2 5
mknod /dev/pc2 b 2 6
mknod /dev/pc3 b 2 7
Set the desired permissions with the chmod command.
Remember, the names (here: df0 and pc0) are arbitrary. However, on Intel Linux systems, the floppy nodes are named /dev/fd*. To access devices under different node-names, just create symlinks. e.g:
ln -sf /dev/pc0 /dev/fd0
ln -sf /dev/pc1 /dev/fd1
ln -sf /dev/pc2 /dev/fd2
ln -sf /dev/pc3 /dev/fd3
Now, MS-DOS drive 0 can be accessed by /dev/fd0 as well as /dev/pc0. If you want /dev/fd0 to be an Amiga drive, link it to /dev/df0 instead. Of course, this are just examples from my configuration. You can choose other names if you like.
After having mount-point and device-node, you can mount your floppy.
For an AmigaOS disk in drive 0:
mount -t affs /dev/df0 /df0
ls /df0
...
umount /df0
For a MS-DOS disk in drive 1:
mount -t msdos /dev/pc1 /pc1
ls /pc0
...
umount /pc0
Warnings:
You can also put this into your /etc/fstab file. Mine looks like this:
# device mountpoint type options freq passno
# --------------------------------------------------------------------------
# Amiga Floppies
/dev/df0 /ados/df0 affs defaults,noauto,noexec 0 2
/dev/df1 /ados/df1 affs defaults,noauto,noexec 0 2
/dev/df2 /ados/df2 affs defaults,noauto,noexec 0 2
/dev/df3 /ados/df3 affs defaults,noauto,noexec 0 2
#
# MS-DOS Floppies
/dev/pc0 /ados/pc0 msdos defaults,noauto,noexec 0 2
/dev/pc1 /ados/pc1 msdos defaults,noauto,noexec 0 2
/dev/pc2 /ados/pc2 msdos defaults,noauto,noexec 0 2
/dev/pc3 /ados/pc3 msdos defaults,noauto,noexec 0 2
I'm not quite sure about the freq/passno fields. Do a "man 5 fstab" and a "man 8 mount" for more info.
Other topics about floppies:
You can use the "mtools" package to access MS-DOS disks without the
need of mount/umount. The mtools-3.6.tar.gz package compiled
without any problems out of the box for me. The nodes /dev/fd0 and
/dev/fd1 are used to access the MS-DOS drives. If you followed my
descriptions above it is not necessary to edit mtools.conf (in /etc or
/usr/local/etc)
Hhm. Good question. There are some binaries in
bin/system/floppy at ftp.uni-erlangen.de.
Unfortunately for me, fdformat dies with a segmentation fault
and amifdformat-formatted disks can't be mounted using
affs. Any suggestions are welcome!
The current affs driver doesn't support Unix-style devices on
Amiga partitions, which makes it impossible to use an Amiga partition
as root. A future release may support an emulation of devices and
other Unix special files, perhaps based on the umsdos
filesystem already available (or you can always try to code the
support yourself).
You can use affs disks as secondary partitions. The AmigaOS 2.0+ symbolic and hard links are used to emulate the similar Unix features (hard links work as expected; soft links outside of the same directory will not work as expected from both sides, because of the differing semantics of AmigaOS and Linux path names).
Yes, if you really know what you are doing. Jesper Skov writes:
We released the first beta version of a Linux 2.1.79 port to Phase5's
Amiga PowerUP hardware on January 29 (1998). A current kernel image
and kernel diffs can be found at:
ftp://sunsite.auc.dk/local/os/linux/apus/
The kernel is still in a beta state and is not suitable for users. We
just decided it was time that we got some feedback from other hackers
- and to let everyone know that APUS (Amiga PowerUP Systems) support
is a work in progress.
Incidentally, the port has been at its current state for a couple of
months, but we have had some problems with Phase5 that have now been
resolved. Phase5 is very interested in seeing this port completed and
has been very helpful lately. We appreciate this very much.
The APUS specific changes should be merged into the vger tree
RSN. Progress reports will be posted on the m68k kernel list.
I will see to that the m68k FAQ is updated on this subject. Please
refer people to www.linux-m68k.org.
Thanks!
JEsper on behalf of:
Roman Zippel : zippel@fh-brandenburg.de
Jes Sorensen : Jes.Sorensen@cern.ch
Jesper Skov : jskov@cygnus.co.uk
There is now an APUS-specific FAQ available on the web at http://sunsite.auc.dk/ftp/projects/apus/docs/faq.html. Information on the Linux/APUS mailing list is in the APUS FAQ.
CyberstormPPC cards are reported to be working well; BlizzardPPC cards appear to be more problematic (they seem to work for some people but not for others). Non-Phase5 PowerPC cards will eventually be supported (when/if they ever make it to market).
Also note that Linux/m68k will work fine with the 680x0 series CPU which is also installed on your PowerUP card.
Some IDE doublers (devices that let you attach up to four IDE devices
to the A1200 and A4000 internal IDE controllers) may work with the
following kernel option: ide=doubler. Those that conform to
the IDEfix "standard" should work without modifications.
Using fbset, you can program video modes (see the framebuffer
documentation in the kernel tree for details). However, there are some
modes built into most drivers that you can specify at boot time: typical
mode names are 640x480, 800x600 and 1024x768. Some cards can also
autodetect the mode you enable in AmigaOS and use it.
As of kernel 2.1.124, here is a fairly comprehensive list of supported modes. "bpp" stands for "bits per pixel": it is the color depth. All modes are non-interlaced unless otherwise specified.
Note: The available minors depend on the kernel version you are using; this discussion pertains to the driver as included the 2.2 kernel series (the 2.0 kernel series does not support the "memory list" options). As of 2.2.1, z2ram has the same capabilities on both Linux/m68k and Linux/APUS.
Basically, the z2ram device driver allows you to use memory that is not being used by Linux/m68k as swap space or a ramdisk (you could use it for a /tmp partition, for example). While the name implies the device only is useful if you have "Zorro II" memory, it actually permits the use of any chip or fast memory on your system that is not already being used by Linux/m68k.
The z2ram driver is enabled using the "Amiga Zorro II ramdisk support" option during kernel configuration. It may already be a module in your default kernel setup.
It is a block device (major 37); you can have a number of different z2ram devices operating at once. Each minor number provides access to different areas of memory:
Minor 1 is most useful if you have Zorro II memory on your system (perhaps on a SCSI controller card) that is slower than the memory on your motherboard or accelerator card, but is still faster than a hard disk. These memory areas are automatically excluded from your system memory during the boot process. Note that you may have Zorro II memory even if you don't have a Zorro bus on your computer (for example, if you have an A500 or A1000 expansion box; PCMCIA memory cards may also be seen as Zorro II memory on the A600 and A1200).
Minors 0 and 2 provide access to chip memory. While this can be useful at times (and chip memory is generally faster than Zorro II memory on the A3000 and A4000), parts of the kernel that expect to be able to get extra chip memory on demand may cause problems. The amifb framebuffer device is one example of a device that may need chip memory "on the fly" (for example, if you increase the depth or size of a framebuffer); amifb may react very poorly to running out of memory it expects to find. If you are using another framebuffer instead of amifb, chip memory access through the z2ram device may be less problematic.
Minor 3 isn't used by anything at the moment.
Minors 4 through 7 were developed for Linux/APUS, but can also be useful under Linux/m68k on Amigas with more than one memory area where the access times to the different types of memory significantly differ (i.e. an Amiga with an accelerator card that has on-board SIMM sockets and other memory on the motherboard or expansion bus). In these situations, you can use the z2ram device in conjunction with the Linux paging code to help ensure that slower memory is only used when the faster memory blocks are completely full. To take advantage of this capability, you should configure your kernel to "Use one physical chunk of memory only" (under the "Advanced options" section after you select the CPU you want to use).
Once you have recompiled your kernel this way, you should make sure the memory block with the best access to your CPU is being used as your main system memory (usually this will be the memory on your accelerator card or on the motherboard), i.e. is listed first when amiboot lists the chunks of memory that have been found. You may need to make a "memory list" for amiboot if the AmigaOS memory priorities are not ordered sensibly. In any event, amiboot will list the chunks of memory it decides are available in the order they should be used; the first chunk listed will be used as your main system memory.
The remaining chunks (actually, the second through fifth chunks... if you have more than five memory chunks, you can hack the driver to permit more) can be used by the z2ram driver using the above-listed minor numbers. So the second chunk on the list will be minor 4, the third chunk will be minor 5, etc.
You have two options: you can use each z2ram area as either swap space
or a partition (but not both at the same time for a particular
instance... although you could put a swap file on a z2ram partition).
Basically all you have to do is enable the z2ram driver in your kernel
and create the block special files you need in /dev; then you
can treat each z2ram area like any other block device (such as a
floppy or hard disk drive).
Note that if you have multiple blocks of memory, you can use some blocks as swap and others as partitions; you just can't use the same memory block for both purposes at once.
Specific instructions for both uses follow:
mknod command. For example, to make a device called
"/dev/fastram" that uses your Zorro II memory, use mknod
--mode=600 /dev/fastram b 37 1. Here 1 is the minor
number used for Zorro II memory (see above), it could also be 0, 2, 4,
5, 6 or 7, as appropriate.
mkswap /dev/fastram.
swapon -p 1 /dev/fastram. The -p
1 parameter tells the kernel to put this swap space in at a
higher priority (1) than the default (a negative number, which depends
on how any swap spaces are already enabled), so it will be used before
your hard disk.
To make this change permanent, you will need to edit your system
startup files to prepare and enable the swap space on each boot (by
adding the "mkswap" and "swapon"lines to one of your early startup
scripts... on Debian, you should add a small script to
/etc/rcS.d around priority S04: see the Debian init
information for more details). Here's a simple init script that will
handle this procedure during each boot:
mkswap /dev/fastram
swapon -p 1 /dev/fastram
If you are using z2ram as a module, you may need to make sure the
module dependencies are available when the script runs so
kmod (assuming you use it) can automatically load the driver.
The principles involved in the ramdisk are similar to those for a swap partition:
mknod command. For example, to make a device called
"/dev/mbram" that uses your motherboard memory (which, I assume for
the purposes of this example, is the second entry on your memory
list), use mknod --mode=600 /dev/mbram b 37 4. Here
4 is the minor number used for the second memory list entry
(see above), it could also be 0, 1, 2, 5, 6 or 7, as appropriate.
mke2fs /dev/mbram will do
the job nicely (you could also use another filesystem format if you
like, but ext2 is probably the best for most uses).
mount -t ext2 /dev/mbram /mnt. The -t
ext2 tells mount that you have an ext2fs filesystem, and should
be changed if you use some other filesystem like Minix.
To set up a /tmp ramdisk for each boot, you should edit your startup scripts to format the ramdisk (since, for obvious reasons, the ramdisk doesn't stay formatted over reboots) and mount it. You may also need to set the permissions for the tmp directory properly on each boot. Here's a sample script that takes care of things:
mke2fs -q /dev/mbram
mount -t ext2 /dev/mbram /tmp
chown root.root /tmp
chmod 1777 /tmp
On a Debian system, this should be dumped into an rcS.d file; see the Debian policy manual for an explanation of the Debian init file scheme. The note under the swap space section about z2ram as a module may also apply.